\documentclass[a4paper,12pt]{article}

\usepackage{fancyhdr}
% \usepackage{ulem}     % do podkreśleń, skreśleń (psuł wygląd tagu \emph)
\usepackage[utf8]{inputenc}
\usepackage{polski}
\usepackage[polish]{babel}
\usepackage{a4wide}

\pagestyle{fancy}
% \chead{Nasz-fotograf.pl ;)}

\renewcommand{\headheight}{16pt}

\newcommand{\HRule}{\rule{\linewidth}{0.1mm}}

\begin{document}

\begin{titlepage}
\begin{center}
	\textsc{Inżynieria oprogramowania - Grupa dra inż. Leszka Grocholskiego}\\
	\textsc{II UWr 2009/2010}\\[4cm]
% 	\HRule\\
	\HRule \\[2cm]
	Aleksandra Kloc, Adam Grycner, Mateusz Łyczek\\[1cm]
	\textsc{\Large Wasza-fota.pl}\\[0.3cm]
	\textsc{\large Dokument wizji}\\[2cm]
% 	\HRule\\
	\HRule\\[2cm]
	
\begin{center}
\textbf{Historia zmian tego dokumentu}
\end{center}
\begin{table}[h]
	\begin{center}
	{\footnotesize
	\begin{tabular}{|l|c|p{2.8cm}|l|}
		\hline
		\textbf{Data} & \textbf{Wersja} & \textbf{Autor} & \textbf{Opis zmian}\\
		\hline
		2009/10/15 & 1.0 & Zespół & Utworzenie dokumentu\\
		2009/10/15 & 1.1 & Mateusz Łyczek & Wstęp, opis produktu\\
		2009/10/15 & 1.1 & Aleksandra Kloc & Opis użytkowników\\
		2009/10/15 & 1.2 & Adam Grycner & Dane statystyczne, środowisko użytkowników\\
		&  &  & Potrzeby użytkowników, rozwiązania alternatywne\\
% 		2009/10/19 & 1.2 & Adam Grycner & Poprawki\\
		2009/10/22 & 1.3 & Adam Grycner & Ogólny opis produktu, Inne wymagania produktu\\
		2009/10/25 & 1.4 & Aleksandra Kloc & Cechy produkty, Atrybuty cech\\
		2009/10/26 & 1.5 & Mateusz Łyczek & Podstawowe przypadki użycia\\
		2009/11/10 & 1.6 & Adam Grycner & Koszty i ceny\\
		\hline
	\end{tabular}
	}
	\end{center}
	\caption{Historia zmian}
\end{table}
	
	
\end{center}
\end{titlepage}

\tableofcontents
\newpage

\section{Wprowadzenie}
\subsection{Cel dokumentu wizji}
Celem niniejszego dokumentu jest ogólne nakreślenie i scharakteryzowanie wymagań stawianych aplikacji ze względu na jej 
przeznaczenie i sposób użycia, a także określenie najważniejszych założeń jego realizacji. Wszelkie decyzje
implementacyjne nie są tu podejmowane i opisane zostaną w następnych dokumentach.

\subsection{Ogólny opis produktu}
Grupa zaangażowanych fotografów dostrzegła potrzebę dotarcia z ofertą do szerszej grupy klientów. Postanowili stworzyć w tym
celu portal internetowy, który ma stanowić łącznik pomiędzy fotografami, a ich potencjalnymi klientami.
Będzie on umożliwiał fotografom umieszczanie zdjęć z imprez takich jak koncerty, wesela, itp. Każdy z nich będzie mógł
utworzyć nową galerię, o ile tylko wykupi odpowiednią ilość miejsca na serwerze. Ceny i ewentualne rodzaje modyfikacji
zdjęć (rozmiar, efekty) będą indywidualnie ustalane przez fotografów przed umieszczeniem fotografii w galerii.

Galerie zostaną udostępnione dla wszystkich użytkowników zarejestrowanych w systemie (galerie publiczne), albo tylko dla
użytkowników posiadających odpowiednie hasło (galerie prywatne). Ponadto system ma umożliwiać wyszukiwanie galerii zdjęć
według nazwy, miejsca i rodzaju imprezy. Zainteresowany kupnem użytkownik będzie miał możliwość zamówienia wybranych zdjęć.
Po dokonaniu zamówienia zostanie ono przesłane do panelu administracyjnego fotografa. Ponadto fotograf zostanie poinformowany
pocztą mailową o zaistniałym zdarzeniu. Przed realizacją zamówienia klient będzie musiał dokonać przelewu na rachunek
fotografa. Wywołanie i dostarczenie zdjęć do klienta będą zadaniami ich autora.

\section{Opis użytkownika}
\subsection{Dane statystyczne dot. użytkowników i rynku}
%wpisałem jakieś lipne dane. nie wiem, czy tak może być
Sprzedaż zdjęć na świecie nieprzerwanie rośnie od kilku lat. Rynek fotograficzny w naszym kraju cechuje naprawdę gigantyczny
wzrost (na poziomie ok. 20\%). Duży wpływ na to ma powszechność internetu. Obecnie 27,9\% zdjęć sprzedawanych jest przy pomocy
internetu, przy czym obroty rynku internetowego wynoszą ok. 37\% obrotów całego rynku fotograficznego. Warto zaznaczyć, że
już 15\% klientów zakładów fotograficznych dokonuje swoich transakcji za pomocą sieci WWW.

\subsection{Opis użytkowników}
\subsubsection{Klienci}
Do tej kategorii należą wszyscy uczestnicy imprez oraz inni zainteresowani zakupem odbitek zdjęć.
Na portalu będą mogli przeszukać bazę zdjęć w celu znalezienia konkretnej imprezy podając jej nazwę lub datę.
Powinni oni mieć dostęp do zdjęć we wszystkich galeriach publicznych i tylko tych galeriach prywatnych, do których
posiadają hasło. Będą też mieli możliwość zamówienia konkretnych odbitek. Od klientów nie wymaga się żadnej
wcześniejszej wiedzy o systemie. Przy każdym kroku zamówienia będzie widoczny opis czynności jakie należy wykonać,
aby poprawnie zakończyć operację.

\subsubsection{Fotografowie}
Do tej kategorii należą wszyscy fotografowie, którzy zarejestrują się w systemie i będą umieszczać zdjęcia w portalu.
Na imprezie, na której świadczą usługi fotograficzne informują oni gości (uczestników) o tym, że odbitki będą mogli
zamówić na tworzonym przez nas portalu, w razie potrzeby (np. w przypadku wesela) podają hasło jakim zabezpieczona będzie
galeria w celu ochrony prywatności osób znajdujących się na zdjęciach. Na portalu powinni oni mieć możliwość modyfikowania
tylko własnych galerii. Nie powinni mieć dostępu do danych innych użytkowników systemu.
Od fotografów nie wymaga się żadnej wcześniejszej wiedzy o systemie.

\subsubsection{Administratorzy}
Administratorzy to użytkownicy odpowiedzialni za poprawne działanie systemu. Czuwają oni nad zawartością zdjęć umieszczanych
na portalu (czy nie zawierają treści zabronionych, czy nie ma plagiatów) i reagują na wszelkie nadużycia. Są odpowiedzialni
za wyciągnięcie odpowiednich konsekwencji w przypadku nieuczciwych fotografów (wyłudzenia itp.).
Dlatego będą mieć dostęp do wszystkich danych związanych z działaniem systemu i mieć możliwość usuwania niecenzuralnych zdjęć oraz
zablokowania bądź usunięcia kont nieuczciwych fotografów.
%\sout{Dostęp do informacji o użytkownikach systemu powinni otrzymywać tylko w
%sytuacjach, w których jest to niezbędne.}\footnote{Nie wiem czy tego zdania nie wykreślić, bo oni muszą mieć non-stop
%dane o użytkownikach, żeby móc ich kontrolować co wrzucają i mieć możliwość ich zablokowania lub usunięcia}

\subsection{Środowisko użytkowników}
Użytkownicy będą korzystać z portalu za pomocą przeglądarki internetowej, dlatego portal powinien bezbłędnie wyświetlać
się w~każdej
z dostępnych na rynku przeglądarkach  internetowych.

\subsection{Podstawowe potrzeby użytkownika}
Klienci internetowych zakładów fotograficznych nie należą do grupy osób dobrze zaznajomionych z technologiami internetowymi.
Tworzony portal fotograficzny powinien być, jak najprostszy w obsłudze. Dodatkowo użytkownicy takich systemów są bardzo wymagający.
Należy dostarczyć im szerokie spektrum wyboru formatu zamawianych zdjęć.
Z drugiej strony fotografowie potrzebują nieskomplikowanych narzędzi do publikowania zdjęć oraz pragną dotrzeć do jak największej
grupy klientów.
%Fotografowie będą chcieli mieć łatwe
%wrzucanie galerii na serwer przez wysłanie jednego pliku *.zip\footnote{To trzeba by jakoś rozwinąć, ale
%myślę, że to jest dobra droga, wypisać trochę takich ``zachcianek'' klienta, potrzeb fotografów itp.}

\subsection{Rozwiązania alternatywne i konkurencyjne}
Na Polskim rynku istnieję kilka stron, których funkcje pokrywają się z funkcjami naszego serwisu. Jednak albo  są to
strony małych zakładów fotograficznych, albo są to serwisy zajmujące się sprzedażą zdjęć artystycznych.
Takie usługi proponują m.in.
\begin{itemize}
	\item http://alezdjecia.pl/
	\item http://www.zdjecia.sklep.pl/
	\item http://bankizdjec.pl/
	%dodawanie znaku wodnego
	%automatyczne skalowanie zdjęć
\end{itemize}

Są także rozwiązania alternatywne. Istnieje możliwość poszerzenia serwisu o poniższe funkcje, jednakże niski
budżet może uniemożliwić zrealizowanie ich.
\begin{itemize}
	\item odciążenie fotografów od obowiązku wysyłania zdjęć na własną rękę poprzez centrum wysyłania
		zdjęć(fotograf dostarcza odbitki naszemu serwisowi, który jest zobowiązany do dostarczenia zdjęć klientowi)
	\item dodanie możliwości korzystania z  systemów płatności internetowych (PayPal albo inne)
	\item zaimplementowanie programu do łatwiejszego wysyłania zdjęć
\end{itemize}

\section{Ogólny opis produktu}
\subsection{Schemat produktu}
Nasz serwis będzie się składał z kilku logicznych części składowych. Oto najprostszy podział zaproponowany przez
jednego z członków naszego zespołu:
\begin{itemize}
  \item
  interfejs użytkownika (wszystko co klient może zobaczyć na ekranie komputera za pośrednictwem naszego systemu)
  \item
  panel użytkownika (logiczna struktura odpowiedzialna za obsługę klienta)
  \item
  panel fotografa
  \item
  panel administratora
  \item
  baza danych (SZBD)
\end{itemize}

\subsection{Określenie pozycji produktu na rynku}
Serwis przeznaczony jest dla dwóch grup użytkowników. Pierwsza grupa, czyli uczestnicy wszelakich mniej lub bardziej
masowych imprez nie mają na stan obecny możliwości korzystania z jakiegokolwiek serwisu skupiającego fotografów wydarzeń
masowych. Projektowany portal może zapełnić tą niszę. Wymienieni użytkownicy dostaną uproszczony dostęp do licznej
grupy galerii. Druga grupa, czyli fotografowie, nareszcie będą mogli korzystać z serwisu łączącego ich z kolegami po
fachu. Do tej pory żaden portal nie oferował takiej funkcji tej grupie użytkowników.

\subsection{Podsumowanie możliwości}
Wypunktujmy już po raz ostatni, jakie możliwości będzie dostarczał planowany produkt.
\\Klienci
\begin{itemize}
  \item wyszukiwanie zdjęć
  \item zamawianie odbitek w wybranym przez siebie formacie
\end{itemize}
Fotografowie
\begin{itemize}
  \item publikowanie zdjęć
  \item określanie stopnia prywatności (tworzenie galerii prywatnych lub publicznych)
  \item ustalanie dostępnych modyfikacji zdjęć
\end{itemize}

\subsection{Założenia i zależności}
Zakładamy, że odwiedzający serwis to przeciętni użytkownicy Internetu, nie dysponujący duża wiedzą informatyczną.
Dlatego interfejs powinien być przejrzysty i intuicyjny, aby każdy mógł się w nim odnaleźć i w pełni wykorzystać
wszystkie możliwości i funkcje.

\subsection{Koszty i ceny}
\subsubsection{Szacowanie rozmiaru oprogramowania}
W celu oszacowania rozmiaru oprogramowania posłużymy się metodą punktów funkcyjnych. Wstępne oszacowanie (UT) przedstawia poniższa tabela:
\begin{center}
\begin{tabular}{|l|l|l|l|l|}
\hline
\textbf{Typ funkcji} & \textbf{Proste} & \textbf{Średnie} & \textbf{Złożone} & \textbf{Razem} \\ \hline
Wejście & 10 X 3 & 5 X 4 & 3 X 6 & 68 \\
Wyjście & 6 X 4 & 4 X 5 & 1 X 7 & 44 \\
Zapytania & 2 X 3 & 20 X 5 & 10 X 6 & 166 \\
Wew. pliki danych & 5 X 7 & 2 X 10 & 5 X 15 & 130 \\
Zew. interfejs & 0 X 5 & 2 X 7 & 4 X 10 & 54 \\ \hline
\multicolumn{4}{|l|}{Wstępne oszacowanie} & 462 \\ \hline
\end{tabular}
\end{center}
Współczynniki wpływu są następujące (każdy z nich jest wartością całkowitą z zakresu $0..5$, gdzie $0$ -- nie dotyczy; $5$ -- zasadnicze znaczenie):

\begin{enumerate}
\item Czy jest wymagane przesyłanie danych? 5
\item Czy są funkcje przetwarzania rozproszonego? 5
\item Czy wydajność ma kluczowe znaczenie? 5
\item Czy system ma działać w mocno obciążonym środowisku operacyjnym? 3
\item Czy system wymaga wprowadzenia danych on-line? 5
\item Czy wewnętrzne przetwarzanie jest złożone? 5
\item Czy kod ma być re-używalny? 4
\item Czy wejścia, wyjścia, pliki i zapytania są złożone? 5
\item Czy wprowadzanie danych on-line wymaga transakcji obejmujących wiele ekranów lub operacji? 4
\item Czy pliki główne są aktualizowane on-line? 5
\item Czy system ma mieć automatyczne konwersje i instalacje? 3
\item Czy system wymaga mechanizmu kopii zapasowych i odtwarzania? 5
\item Czy system jest projektowany dla wielu instalacji w różnych organizacjach? 5
\item Czy aplikacja jest projektowana aby wspomagać zmiany i być łatwą w użyciu przez użytkownika? 5
\end{enumerate}   

Suma współczynników wpływu wynosi więc 73. Mnożnik współczynników wpływu liczymy z wzoru:

\[ CM = 0.65 + 0.01 \cdot \textrm{suma współczynników wpływu} \]

a więc w naszym przypadku CM = 1.36. Aby obliczyć punkty funkcyjne korzystamy z wzoru:

\[ FP = UT \cdot CM \]

W naszym przypadku:

\[ FP = 462\cdot 1.37 = 632\]

Żeby uzyskać szacowaną ilość wierszy kodu (LOC, ang. Lines of code) należy pomnożyć FP razy współczynnik ,,zwięzłości języka'', który szacujemy na 21 (Python) oraz 20 (PHP). Około 2/5 kodu będzie napisana w pythonie, a 3/5 napisana w PHP. Wobec powyższych obliczeń, szacowana ilość linii kodu wynosi 13 911 linii, w zaokrągleniu 14 000.


\subsubsection{Szacowanie pracochłonności}
Do oszacowania pracochłonności projektu wykorzystamy metodę COCOMO II (model post-architektoniczny). Jednostką używaną w tej metodzie jest PM (osobomiesiąc). Podstawowy wzór określający pracochłonność ($PM_\textrm{nominal}$):

\[ PM_{\textrm{nominal}} = A \cdot \textrm{Size}^E \]

gdzie A jest stałą dobraną doświadczalnie, u nas równą 1.52, Size wartością w KSLOC (tysiącach linii kodu) a E wyraża się wzorem:

\[ E = B + 0.01 \cdot \sum_{i=1}^5 SF_i \]

gdzie B jest stałą dobraną doświadczalnie, u nas równą 0.88, a $SF_i$ to czynniki skali. Wartości czynników skali przedstawia poniższa tabela:

\begin{center}
\begin{tabular}{|l|l|l|} \hline
\textbf{Nazwa czynnika} & \textbf{Ocena} & \textbf{Wartość} \\ \hline
\textbf{Typowość} & Low & 2.96 \\
\textbf{Elastyczność} & High & 2.01 \\
\textbf{Zarządzanie ryzykiem} & Nominal & 5.24 \\
\textbf{Spójność zespołu} & Nominal & 8.29 \\
\textbf{Dojrzałość procesu wytwarzania} & Low & 5.24 \\ \hline
\end{tabular}
\end{center}


Czynnik E jest więc równy $0.88 + 0.01 \cdot 23.74 = 1.11$. Obliczymy teraz pracochłonność projektu:

\[ PM_{nominal} = 1.52 \cdot 14^{1.11} = 28. \]

Uzyskane wyniki znajdują się w tabeli \ref{t:wyniki}:
\begin{table}[h]
\begin{center}
\begin{tabular}{|l|l|}
\hline
\textbf{Nazwa} & \textbf{Wartość}\\
\hline
Osobo-miesiące & $28$\\
Osobo-dni & $784$\\
Osobo-godziny & $6120$\\
\hline
\end{tabular}
\end{center}
\caption{Wyniki}
\label{t:wyniki}
\end{table}

Przy założeniu, że koszt zatrudnienia programisty, to 3500 zł miesięcznie, na zatrudnienie 15 osobowego zespołu będziemy potrzebowali 28 * 1,5 * 3500 = 147 000 zł.

\subsubsection{Koszt sprzętu}
W celu zapewnienia najwyższej jakości naszych usług bedziemy potrzebowali serwerów o sporej mocy i gigantycznej pamięci. Koszt zakupu serwera WWW szacujemy na 10 000 zł, a koszt zakupu serwera baz danych na 8 000 zł. Łączny koszt oceniamy na 110 000 zł.






\section{Cechy produktu}

\subsection{Użyteczność} 
Interfejs musi zostać tak zaprojektowany, aby niedoświadczeni użytkownicy nie mieli problemu z obsługą systemu.
Korzystanie z serwisu powinno być intuicyjne.

\subsection{Możliwość rozbudowania}
System powinien zostać tak zaprojektowany, aby dodanie kolejnych funkcji nie wymuszało dużych zmian w dotychczasowej
implementacji.

\subsection{Efektywność}
System powinien być w stanie obsłużyć wielu użytkowników w czasie rzeczywistym niezależnie od ich łącza.

\subsection{Bezpieczeństwo}
System powinien zapewnić bezpieczeństwo danych użytkowników zgromadzonych w systemie.

\subsection{Niezawodność}
System powinien być zabezpieczony przed utratą danych.


\section{Atrybuty cech}
Każda z cech jest opisana przez zestaw trzech atrybutów:
\begin{itemize}
   \item Priorytet – Priorytet wprowadzenia do projektu danej cechy. Stopniowanie: wysoki, średni, niski.
   \item Ryzyko – Prawdopodobieństwo wystąpienia niepożądanych zdarzeń w realizacji cechy. Stopniowanie: duże, średnie, małe.
   \item Stabilność – Prawdopodobieństwo tego, że cecha nie zostanie zmodyfikowana. Stopniowanie: pewna, średnia, mała.
\end{itemize}

\subsection{Użyteczność}
Okno aplikacji powinno zostać podzielone na części, a mianowicie na: menu (odnośniki do głównych części portalu),
pomoc kontekstową (przewodnik poruszania się po portalu i korzystania z aktualnie realizowanej przez użytkownika
funkcji) oraz trzecią i główną część, której zawartość będzie się zmieniać w zależności od wybranego odnośnika menu.
Układ ten został zastosowany w wielu stronach www, więc możemy założyć, że jest on znany dla użytkownika.
     \begin{itemize}
     \item Priorytet : wysoki
     \item Ryzyko : małe
     \item Stabilność : pewna
     \end{itemize}

\subsection{Możliwość rozbudowania}
System powinien zostać podzielony na części. Chcemy, aby każda z nich działała niezależnie od reszty, tzn.
aby wymiana jednej części nie wymagała zmian w pozostałych.
     \begin{itemize}
     \item Priorytet : średni
     \item Ryzyko : średnie
     \item Stabilność : średnia
     \end{itemize}

\subsection{Efektywność}
System powinien być w stanie obsłużyć stu użytkowników w czasie rzeczywistym niezależnie od prędkości ich łącza
internetowego. W szczególności: czas dostępu do bazy - 0.5 sekundy, przepustowość upload - 1 Mbit/s, przepustowość
download - 100 Mbit/s.
     \begin{itemize}
     \item Priorytet : średni
     \item Ryzyko : średnie
     \item Stabilność : średnia
     \end{itemize}

\subsection{Bezpieczeństwo}
Hasło dostępu oraz login użytkowników powinny być zaszyfrowane, a dostęp do nich chroniony hasłem. Zgodnie z ustawą
o ochronie danych osobowych dostęp do informacji o użytkownikach powinien być zablokowany dla osób nieuprawnionych.
      \begin{itemize}
      \item Priorytet : wysoki
      \item Ryzyko : małe
      \item Stabilność : pewna
      \end{itemize}

\subsection{Niezawodność}
W tym celu zabezpieczenia systemu przed utratą danych należy zadbać o cogodzinne tworzenie kopii zapasowych.
System powinien działać przez 90\% czasu w ciągu roku.
     \begin{itemize}
     \item Priorytet : średni
     \item Ryzyko : średnie
     \item Stabilność : średnia
      \end{itemize}

\section{Podstawowe przypadki użycia}
Prześledźmy teraz najważniejsze przypadki użycia tworzonego portalu wasza-fota.pl. Wyróżniamy w nich trzech aktorów:
\begin{description}
	\item[Klient] osoba odwiedzająca portal pragnąca zamówić odbitki zdjęć
	\item[Fotograf] osoba robiąca zdjęcia, udostępnia je klientom do zamówienia
	\item[Administrator] osoba dbająca o porządek w serwisie, odpowiedzialna za zarządzanie sprzedażą pakietów i
				przestrzeganie zasad
\end{description}

\subsection{Zamówienie pakietu}
\emph{Aktor: Fotograf}\\
Fotograf po zarejestrowaniu otrzymuje jedną darmową galerię, żeby mógł wypróbować działanie serwisu. Jeśli zdecyduje się
na umieszczanie zdjęć w serwisie, musi wykupić pakiet miejsca na serwerze. W tym celu loguje się do panelu fotografa
i~wybierając odpowiednią pozycję z menu może zobaczyć dostępne do wykupienia pakiety. Wykorzystując odpowiedni przycisk
interfejsu dokonuje zamówienia na pakiet potrzebnej przestrzeni dyskowej serwera.

\subsection{Akceptacja pakietu}
\emph{Aktor: Administrator}\\
Administrator po zalogowaniu się do panelu administratora widzi powiadomienia o prośbach fotografów o przydzielenie
im miejsca na dysku serwera. Wybierając odpowiednią pozycję w menu panelu przechodzi do działu obsługi pakietów przestrzeni
dyskowej serwera. Może tam zaakceptować zamówienie \emph{fotografa} na miejsce na dysku (po uprzednim upewnieniu się, że ten
za odpowiednią ilość miejsca zapłacił).

\subsection{Utworzenie galerii i dodanie zdjęć}
\emph{Aktor: Fotograf}\\
Jeśli fotograf posiada już ważny pakiet na miejsce na dysku może teraz tworzyć galerie. W tym celu loguje się do panelu fotografa
i w odpowiednim dziale może utworzyć galerię podając jej nazwę, datę imprezy i ustalając poziom widoczności galerii:
publiczna, czy prywatna (z hasłem dostępu, które jest w tym miejscu ustawiane). W formularzu ma też możliwość od razu załączenia
pliku \verb+zip+ zawierającego zdjęcia, które pragnie udostępnić \emph{klientom} do kupienia. Plik ten musi spełniać określone
w pomocy kontekstowej ograniczenia takie jak ilość zdjęć (która jest ograniczona na pojedynczą galerię) czy ich rozmiary (żeby
miejsce na serwerze za szybko się nie skończyło).

\subsection{Ustalenie cen za usługi}
\emph{Aktor: Fotograf}\\
Fotograf w panelu fotografa po zalogowaniu może w specjalnym dziale ustalić ceny swoich usług. Określa tam jakie usługi oferuje:
na jakich formatach i rodzajach papieru wywołuje zamówione odbitki i jakie pozwala wybrać efekty (np. konwersja zdjęcia do
wersji czarno-białej). Dla każdego typu usług podaje też jej cenę.

\subsection{Wyszukiwanie imprez}
\emph{Aktor: Klient}\\
Klient po wejściu na stronę może skorzystać z prostej i intuicyjnej jednak bardzo użytecznej i pomocnej wyszukiwarki imprez.
W tym celu klient podaje datę imprezy bądź jej nazwę i~może szybko znaleźć i zamówić interesujące go zdjęcia. Wyszukiwanie
pozwala zaoszczędzić czas nie zmuszając \emph{klientów} do żmudnego przeglądania kolejnych galerii w poszukiwaniu tej,
która zawiera zdjęcia z interesującej go imprezy.

\subsection{Przeglądanie i zamawianie zdjęć}
\emph{Aktor: Klient}\\
Po znalezieniu poszukiwanej galerii \emph{klient} może ją przeglądać. Każde zdjęcie może zostać powiększone, pozwalając przy
okazji określić parametry zamówienia: na jakim papierze i w jakim rozmiarze wywołać dane zdjęcie, jakie zastosować efekty.
Przeglądarka galerii służy właśnie głównie zamawianiu zdjęć przez \emph{klientów}, którzy mogą też na bieżąco widzieć ile
i które zdjęcia zamówili i w każdej chwili zmodyfikować swój wybór. Po wybraniu zdjęć i określeniu sposobu ich wywołania
klient przechodzi do najważniejszej części procesu zamówienia odbitek. Musi podać swoje dane osobowe: imię i nazwisko oraz
adres na jaki należy przesłać wywołane odbitki. Widzi też podsumowanie swojego zamówienia, które może wydrukować, a które
podaje mu ile należy zapłacić fotografowi za każde zdjęcie i na jakie konto bankowe to uczynić. Otrzymuje też numer
identyfikacyjny swojego zamówienia, który będzie mu potrzebny przy dalszej realizacji zamówienia.

\subsection{Realizacja zamówienia}
\emph{Aktorzy: Fotograf, Klient}\\
Fotograf w panelu fotografa może zobaczyć wysłane do niego zamówienia. Po wybraniu jednego z nich widzi jego szczegóły.
Zestawienie pokazuje mu które zdjęcia powinien wywołać i z jakimi parametrami (rozmiar, rodzaj papieru, efekty). Otrzymuje też
adres \emph{klienta}, na który wyśle później odbitki. W panelu fotografa zaznacza obok zamówienia jaki jest jego status:
oczekujące, przyjęte do realizacji, realizowane, wysłane. \emph{Klient} korzystając z otrzymanego przy składaniu zamówienia
numeru identyfikacyjnego może przez jego podanie w odpowiednim miejscu serwisu sprawdzić stan swojego zamówienia.

\subsection{Modyfikacja ustawień galerii}
\emph{Aktor: Fotograf}\\
Z biegiem czasu albo w wyniku błędu (literówka, niedopatrzenie przy pakowaniu zdjęć do wysłania) \emph{fotograf} może mieć
potrzebę zmiany ustawień galerii, a konkretnie jej nazwy, hasła lub zawartości. Może tego dokonać w panelu fotografa po
zalogowaniu się. Ma możliwość usunięcia wybranych zdjęć a także dodania pojedynczych nowych zdjęć. Oprócz tego musi mieć
możliwość zmiany nazwy oraz hasła galerii i daty imprezy.

\subsection{Blokowanie konta fotografa i inne czynności administracyjne}
\emph{Aktor: Administrator}\\
Istnieją też niestety ludzie, którzy będą chcieli wykorzystać serwis niezgodnie z jego przeznaczenie, nierzadko łamiąc przy
tym prawo. Aby zaradzić takim sytuacjom administrator serwisu ma możliwość zablokowania konta fotografa, który nie przestrzega
regulaminu. Blokuje konto na nieokreślony czas, po którym może je odblokować. W przypadku braku odpowiedzi fotografa i
uregulowania (wyjaśnienia) sprawy bądź bardzo poważnego naruszenia regulaminu (albo prawa) \emph{administrator} ma możliwość
usunięcia konta fotografa wraz ze wszystkimi galeriami przez niego utworzonymi. Tej czynności nie da się już odwrócić.
Poza wymienionymi czynnościami administrator zarządza pakietami miejsca na dysku serwera, wykonuje kopie zapasowe i w razie
potrzeby przywraca przy ich pomocy serwis do poprzedniego stanu oraz sprawuje ogólną pieczę nad odpowiednim działaniem serwisu.


\section{Inne wymagania produktu}
\subsection{Spełniane normy}
Aplikacja będzie serwisem internetowym. Z tego powodu powinna posiadać interfejs zgodny ze standardami organizacji W3C.
Kod strony powinien być zgodny ze standardem XHTML 1.0, a arkusz stylów ze standardem CSS 2.0.
Serwis będzie także spełniał wszystkie normy prawne (ustawa o ochronie danych osobowych, kontrola treści niecenzuralnych).

\subsection{Wymagania stawiane systemowi}
System będzie aplikacją online, zainstalowaną na serwerze pracującym pod kontrolą systemu operacyjnego Linux.
Ze względu na prognozowane duże natężenie ruchu, maszyna powinna cechować się dużą mocą obliczeniową oraz łączem o dużej
przepustowości. Ponadto portal powinien być bezpieczny i stabilny, dlatego niezbędne będzie oprogramowanie do wykonywania
regularnych kopii zapasowych. Oprócz tego klienci oczekują prostoty użytkowania. Z tego powodu portal będzie wyposażony
w dział FAQ oraz przy każdej operacji będzie wyświetlana krótka instrukcja.
Dodatkowo serwis będzie świadczył usługę wystawiania faktur.

\subsection{Wymagania efektywnościowe}
Serwis powinien być tak napisany, aby mogła z niego korzystać duża liczba użytkowników. Z tego powodu zostaną użyte
wydajne języki programowania oraz dobrze zoptymalizowane SZBD. Oprócz tego niezbędne są serwery o dużej
pojemności i szybkim czasie odczytu danych.


\section{Wymagania dokumentacyjne}
\subsection{Wymagania dokumentacyjne}
Aplikacja powinna zostać tak zaprojektowana, aby żaden z użytkowników nie miał problemu z jej obsługą. Interfejs użytkownika
powinien być użyteczny oraz wzbogacony o pomoc kontekstową i instrukcję korzystania z serwisu przedstawiającą jego podstawowe
funkcje.

\subsection{Pomoc on-line}
Użytkownik powinien mieć łatwy dostęp do formularza zgłaszania błędów.


\section{Słownik}
\begin{description}
	\item[upload] - proces (przeciwny do \emph{download}) polegający na wysyłaniu przez użytkownika danych na serwer
	\item[download] - proces (przeciwny do \emph{upload}) polegający na pobieraniu przez użytkownika danych z serwera
	\item[czas rzeczywisty] - określenie funkcjonowania systemu informatycznego, którego reakcja dostrzegalna jest
					bez widocznego opóźnienia
	\item[pomoc on-line] - indywidualne udzielenie pomocy przez kontakt wirtualny (przy użyciu internetu)
	\item[łącze internetowe] - połączenie, które umożliwia użytkownikowi korzystanie ze wszystkich zasobów sieci
	\item[interfejs użytkownika] - część oprogramowania odpowiedzialna za interakcję z użytkownikiem
	\item[pomoc kontekstowa] - informacja pomocnicza wyświetlana na ekranie w zależności od sytuacji, w jakiej znalazł
					się użytkownik systemu
	\item[panel fotografa] - strona www przeznaczona dla fotografów, pozwalająca im po zalogowaniu się zarządzać swoim
					kontem w serwisie, dodawać i edytować galerie oraz ustalać ceny za swoje usługi
	\item[pakiet miejsca na serwerze] - fotografowie kupują je, aby mieć miejsce na serwerze, gdzie mogliby umieszczać
					swoje galerie. Są ich różne typy, każdy gwarantujący inną ilość miejsca
	\item[galeria] - miejsce w serwisie, gdzie fotograf może umieszczać swoje zdjęcia, a klient je przeglądać i wybrane
					zamówić
\end{description}


\end{document}
